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(57) Abstract 

A multiple network protocol encoder/decoder comprising a network protocol layer (101), data handler (102), O.S. State machine 
(104), and memory manager (103) state machines implemented at a hardware gate level. Network packets are received from a physical 
transport level mechanism by the network protocol layer state machine (101) which decodes network protocols such as TCP, IP, user Data 
Protocol (UDP), PPP, and Raw Socket concurrently as each byte is received. Each protocol handler parses and strips header information 
immediately from the packet, requiring no intermediate memory. The resulting data are passed to the data handler (102) which consists 
of data state machines (104) that decode data formats such as email, graphics, Hypertext Transfer Protocol (HTTP), Java, and Hypertext 
Markup Language (HTML). Each data state machine (104) reacts accordingly to the pertinent data, and any data that are required by more 
than one data state machine (104) is provided to each state machine concurrently, and any data required more than once by a specific 
data state machine, are placed in a specific memory location (206) with a pointer designating such data; thereby ensuring minimal memory 
usage. Resulting display data are immediately passed to a display controller (205). Any outgoing network packets are created by the data 
state machines and passed through the network protocol state machine which adds header information and forwards the resulting network 
packet via a transport level mechanism. 
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WO 98/19412 PCT/US97/17257 

MULTIPLE NETWORK PROTOCOL ENCODER/DECODER 
AMD DATA PROCESSOR 



5 BACKGROUND OF THE INVENTION 

TECHNICAL FIELD 

The invention relates to network protocols and data packets. More particularly, the 
1 0 invention relates to the decoding of network protocols and processing of packet 
data during packet reception without the time-consuming overhead of software or 
software/hardware implementations. In addition, the invention allows one pass 
parsing of the data, eliminating the buffering of data packets for different stacks, 
and thus minimizing the memory usage. 

15 

DESCRIPTION OF THE PRIOR ART 

Computer networks necessitate the provision of various communication protocols 
to transmit and receive data. Typically, a computer network comprises a system of 

20 devices such as computers, printers and other computer peripherals, 
communicatively connected together. Data are transferred between each of these 
devices through data packets which are communicated through the network using 
a communication protocol standard. Many different protocol standards are in 
current use today. Examples of popular protocols are Internet Protocol (IP), 

25 Internetwork Packet Exchange (IPX), Sequenced Packet Exchange (SPX), 
Transmission Control Protocol (TCP), and Point to Point Protocol (PPP). Each 
network device contains a combination of hardware and software that translates 
protocols and process data. 

30 An example is a computer attached to a Local Area Network (LAN) system, 
wherein a network device uses hardware to handle the Link Layer protocol, and 
software to handle the Network, Transport, and Communication Protocols and 
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information data handling. The network device normally implements the one Link 
Layer protocol in hardware, limiting the attached computer to only that particular 
LAN protocol. The higher protocols, e.g. Network, Transport, and Communication 
protocols, along with the Data handlers, are implemented as software programs 

5 which process the data once they are passed through the network device 
hardware into system memory. The advantage to this implementation is that it 
allows a general purpose device such as the computer to be used in many 
different network setups and support any arbitrary network application that may be 
needed. The result of this implementation, however, is that the system requires a 

10 high processor overhead, a large amount of system memory, complicated 
configuration setup on the part of the computer user to coordinate the different 
software protocol and data handlers communicating to the computer's Operating 
System (O.S.) and computer and network hardware. 

15 This high overhead required in processing time is demonstrated in U.S. Pat. No. 
5,485,460 issued to Schrier et al on 16 January 1996, which teaches a method of 
operating multiple software protocol stacks implementing the same protocol on a 
device. This type of implementation is used in Disk Operating System (DOS) 
based machines running Microsoft Windows. During normal operation, once the 

20 hardware verifies the transport or link layer protocol, the resulting data packet is 
sent to a software layer which determines the packets frame format and strips any 
specific frame headers. The packet is then sent to different protocol stacks where 
it is evaluated for the specific protocol. However, the packet may be sent to 
several protocols stacks before if is accepted or rejected. The time lag created by 

25 software protocol stacks prevent audio and video transmissions to be processed 
in real-time; the data must be buffered before playback. It is evident that the 
amount of processing overhead required to process a protocol is very high and 
extremely cumbersome and lends itself to applications with a powerful Central 
Processing Unit (CPU) and a large amount of memory. 

30 

Consumer products that do not fit in the traditional models of a network device are 
entering the market. A few examples of these products are pagers, cellular 
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phones, game machines, smart telephones, and televisions. Most of these 
products have small footprints, 8-bit controllers, limited memory or require a very 
limited form factor. Consumer products such as these are simplistic and require 
low cost and low power consumption. The previously mentioned protocol 
5 implementations require too much hardware and processor power to meet these 
requirements. The complexity of such implementations are difficult to incorporate 
into consumer products in a cost effective way. If network access can be simplified 
such that it may be easily manufactured on a low-cost, low-power, and small 
form-factor device, these products can access network services, such as the 
10 Internet. 

SUMMARY OF THE INVENTION 

The invention provides a low-cost, low-power, easily manufacturable, small 
1 5 form-factor network access module which has a low memory demand and 
provides a highly efficient protocol decode. The invention comprises a 
hardware-integrated system that both decodes multiple network protocols in a 
byte-streaming manner concurrently and processes packet data in one pass, 
thereby reducing system memory and form factor requirements, while also 
20 eliminating software CPU overhead. 

The preferred embodiment of the invention comprises a network protocol layer, 
data handler, O.S. State Machine, and memory manager state machines 
implemented at a hardware gate level. Network packets are received from a 

25 physical transport level mechanism by the network protocol layer state machine. 
The protocol state machine decodes network protocols such as TCP, IP, User 
Datagram Protocol (UDP), PPP, and Raw Socket concurrently as each byte is 
received. Each protocol handler parses, interprets, and strips header information 
immediately from the packet, requiring no intermediate memory. The resulting 

30 data are passed to the next protocol layer or data handler for which the latter case 
consists of data state machines that decode data formats such as email, graphics, 
Hypertext Transfer Protocol (HTTP), Java, and Hypertext Markup Language 
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(HTML). Each data state machine reacts accordingly to the pertinent data, and 
any data that are required by more than one data state machine are provided to 
each state machine concurrently. Any data that are required more than once by a 
specific data state machine, are placed in a specific memory location with a 
5 pointer designating such data (thereby ensuring minimal memory usage). 
Resulting display data are immediately passed preformatted to a display 
controller. Any outgoing network packets are created by the data state machines 
and passed through the network protocol state machine which adds formats to the 
packet, and checksums the information header information, and forwards the 
1 0 resulting network packet via a physical transport level mechanism. 

The preferred embodiment does not necessarily require a CPU and software to 
process the network packets, thereby greatly reducing system cost. The hardware 
gate level implementation provides a modular, embeddable design whereupon 
15 the designer may pick and choose the functionality that the particular application 
requires and still retain a low cost, low power, small form factor. 

BRIEF DESCRIPTION OF THE DRAWINGS 

20 Fig. 1 is a high-level data flow diagram of the core system according to the 
invention; 

Fig. 2 is a high-level block diagram of a system according to the invention; 

25 Fig. 3 is a functional block diagram of a complete system implementation 
according to the invention; 

Fig. 3A is a functional block diagram of the UMA memory controller according to 
the invention; 

30 

Fig. 4 is a time comparison chart illustrating data task time requirements for a 
traditional architecture and the invention. 
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Fig. 5 illustrates the possible progression of applications according to the 
invention; 

5 Fig. 6 illustrates the concept of an Internet Tuner according to the invention; 
Fig. 7 illustrates two implementations according to the invention; 
Fig. 8 illustrates Network PC implementations according to the invention; 

10 

Fig. 9 illustrates Handheld Devices implementations according to the invention; 

Fig. 10 illustrates Smart Telephone implementations according to the invention; 

15 Fig. 11 illustrates Smart Television, cable-box, Video Cassette Recorder (VCR), 
Digital Video Disc (DVD) and game machine implementations according to the 
invention; and 

Fig. 12 is a timing diagram sharing a received packet according to the invention; 
20 and 

Fig. 13 is a block schematic diagram showing signal flow for the packet of claim 12 
according to the invention. 

25 DETAILED DESCRIPTION OF THE INVENTION 

Referring to FIG. 1, the invention comprises a Network Protocol Layer 101, a Data 
Handler 102, a Memory Control module 103, and an Operating System (O.S.) 
State Machine module 104, each implemented at the hardware gate level. The 
30 Network Protocol Layer 101 decodes incoming and encodes outgoing network 
packets. The Network Protocol Layer 101 comprises a plurality of state machines 
representing different network protocol stacks (i.e. PPP, TCP, IP, UDP, and Raw 
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Socket) which simultaneously decode incoming network packets. The 
implementation of the protocol stacks in gate level logic allows the real time 
decoding of the network packet as the packet is received, thereby requiring no 
temporary memory storage. After all of the packet header information is stripped 
5 out and verified by the state machines, the resulting data is passed to the Data 
Handler 102. The Data Handler 102 comprises a plurality of state machines, each 
of which process a specific data type (i.e. HTTP, email formats (Post Office 
Protocol (POP3), Internet Message Access Protocol (IMAP4), Simple Mail Transfer 
Protocol (SMTP)), graphics standards (Joint Photographic Experts Group (JPEG), 

10 Graphics Interchange Format (GIF)), Java, and HTML). The gate level 
implementation of the data handlers enable the invention to concurrently process 
received data in real time and is especially suitable for applications which handle 
streams of data as they are received, i.e. Java, HTML, POP3 email, and audio and 
video applications. Any data that are required by more than one data state 

1 5 machine are provided in a concurrent manner. Any data required more than once 
by a specific data state machine are placed in a specific memory location with a 
pointer designating them. All memory accesses are arbitrated through the 
Memory Control module 103. Any resulting display data are also routed through 
the Memory Control module 103. The O.S. State Machine 104, acts as an 

20 arbitrator between all of the state machines for resource control, system, and user 
interface. Any user input is interpreted by the O.S. State Machine and routed to 
the Data Handler 102. 

As an example, a data handler that interprets HTML format could decode the 
25 HTML tags using a Cyclic Redundancy Check (CRC) calculation. HTML format 
contains character strings known as tags, which control the formatting of a 
subsequent block of text when displayed on a video output device. These tags 
may be efficiently decoded by generating a CRC number for a given tag and using 
said number to enable a formatting instruction. Such a decoding algorithm is 
30 suited for gate level implementation and provides for an HTML encoded document 
to be displayed on a video output device much more quickly than is currently 
possible. 
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Although the invention is described as being at the hardware gate level, one 
skilled in the art can readily appreciate that these functions may be implemented 
in many other ways such as Programmable Array Logic (PALs), General Array 
5 Logic (GALs), Read Only Memory (ROMs), and software. Additionally, specific 
protocols and data types have been indicated and one skilled in the art can 
readily appreciate that the modularity of the invention does not limit it to those 
specific protocols or data types. 

10 Turning to FIG. 2, the invention is represented in a high-level block diagram. This 
diagram describes the operational task of each module in a full implementation of 
the invention. The O.S. State Machine 208, contains the system "glue" logic, and 
the device control interface, and acts as a "traffic cop" between the state machines 
of the other modules. The Network Protocol Layer 207, contains state machines 

15 for TCP/IP, UDP, Raw Socket, and PPP protocols. The Memory Control module 
206 contains the logic for the Unified Memory Architecture (UMA) which allows the 
system and video display memory to reside in the same memory area. A Display 
Controller 205 provides control of a VGA, television standard, or other type of 
display. Four data handlers are used in this implementation. An Email data 

20 handler 201 interprets both POP3 and IMAP4 formats. Interpreters 202 are 
implemented which decode JPEG and GIF formats (commerce and telephony 
standards may also be decoded). A Java Machine 203 is also included which 
interprets the Java language byte codes. The World-Wide Web (WWW) Browser 
204, contains an HTML decoder/accelerator, HTTP Data handler and an 

25 integrated email state machine. 

As an example, an incoming JPEG image packet is traced through the system, 
assuming a MODEM physical transport. The request starts with the user indicating 
a desire to download a given JPEG image by typing on keyboard 321 . This input 
30 is interpreted by the keyboard interface 316 and passed to the O.S. State machine 
315. O.S. State machine 315 processes the input and passes it as a command to 
the HTTP client 311. The HTTP client creates a request packet and passes it via 
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the Port Decoder 309 to the TCP Layer 308. The TCP Layer prepends the 
appropriate TCP header and passes it to the IP Layer 307. The IP layer then 
prepends the appropriate IP header and passes the packet to the PPP Layer 306. 
The PPP Layer prepends the appropriate header, appends an FCS, and passes 

5 the data to the Physical Transport Interface 305. The Physical Transport Interface 
serializes the data into a bit stream and sends the packet to the MODEM unit 304. 
When the request is accepted by the host server, it sends the requested JPEG 
image back to the client system. The data are first received by the MODEM 304 
which indicates to the Physical Transport Interface 305 that data are present. The 

10 Physical Transport interface then reads the bit serial data from the MODEM, 
converts it to a parallel byte data, and indicates to the PPP Layer 306 that data are 
present. The PPP Layer reads in the received bytes. When it detects a valid start 
byte, it begins to parse the incoming bytes. When the byte stream reaches the 
PPP protocol field, the PPP Layer decodes it, and in this example decodes the 

15 embedded packet as being of type IP. In response to this protocol byte, the PPP 
Layer enables the IP Layer 307 and indicates to it that IP data are being received. 
All further data bytes received are now passed directly to the IP Layer. The IP 
Layer then begins to parse the incoming data bytes. When it comes to the IP 
header protocol field, it determines which higher protocol to enable. In this 

20 example, the IP Layer decodes the protocol field as being of type TCP. At this 
point, the IP Layer enables the TCP Layer 308 and indicates to it when TCP data 
are being received. When this indicator goes active, all further data bytes in the 
received packets are sent to both the IP and TCP Layers (IP Layer needs the data 
bytes to complete checksum calculations). The TCP Layer then begins to parse 

25 the incoming data bytes. When it comes to the TCP header destination port field, it 
determines which data handler to enable. In this example, the PORT field 
decodes to the HTTP client 311. At this point, the PORT decoder enables the 
HTTP client and indicate to it that HTTP requested data are being received. The 
HTTP client then begins to parse received data bytes. When the HTTP client 

30 determines that the packet is of type JPEG image, the HTTP client enables the 
JPEG decoder 313. At this point, all data bytes are now routed to the JPEG 
decoder. The JPEG decoder then receives all further incoming data bytes and 
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processes them accordingly. The resulting decoded image is sent to the display 
memory via the Memory Controller 312 to be processed by the Display Controller 
324 for output to display device 326. 

5 As also noted in Fig. 3, various layers need access to a shared memory resource. 
All memory accesses are arbitrated by a single memory controller. This memory 
controller determines which layer or handler has access at any given cycle to the 
unified memory buffer. This memory controller is needed due to the fact that all 
system and display memory buffers are shared within a single memory buffer unit. 

10 The unified memory controller 312 takes read and write requests from the various 
layers, arbitrates the requests based on a dynamic rotating arbitration scheme 
with fixed priority weighting. This algorithm is depicted in Fig. 3A. If, in the 
pictured configuration, device D2 302A and device D3 303A both request memory 
access at the same time, then the arbiter 307A awards the cycle to the device that 

1 5 has not had the most recent memory access. The arbitor 307A then passes its 
memory request to the A input arbitor 309A. If the B input on arbitor 309A is idle, 
then the request is passed up to the B input of arbitor 31 OA. If the A input to the 
arbitor 31 OA is idle, then the request is made to the memory unit. All arbitration 
determinations are performed using combinatorial logic, thereby eliminating any 

20 wait states to any device if no other memory requests are being made. Priority 
weighting is assigned by configuring the arbitration tree structure. In Fig. 3A, 
Device DO 300A and Device D1 301A each have 25% priority weighting meaning 
that if all devices requested constant memory usage, they would each win the 
arbitration 25% of the time. Devices D2 302A, D3 303A, D4 304A, and D5 305A 

25 each have 12.5% priority weighting. The memory controller design is simplified by 
having each of the individual arbitration units having the same logic structure. In 
this scheme, the number of requesting devices, and their priority weighting can 
easily be configured by adding and arranging arbitor units. 

30 Turning to FIG. 4, the speed advantages that the invention offers are much higher 
than the traditional architecture currently in use. The figure represents the time 
needed to complete each task. For a series of packets that require an HTML 
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download 401, decode of the HTML 402, JPEG download 403, decode of the 
JPEG 404, JAVA download 405, decode of the JAVA bytes 406, and streaming 
audio 407, the total time required for these tasks is shown for the traditional 
architecture 408 and the invention (iReady architecture) 409. The invention 409 is 
5 significantly faster for these tasks than the traditional architecture 408. 

Turning to FIG. 5, the progression of applications for this type of network access is 
shown. Presently, the traditional model of the network client is being used, 
namely the computer 501 . The consumer appliance concepts of the Network PC 
10 502, handheld devices 503, smart telephones 504, set-top appliances 505, and 
smart televisions 506 are now becoming a reality. The invention provides these 
products with a cost-effective, space, speed, and power conscious network 
access. 

1 5 Referring to FIG. 6, the invention operates much like a television 602 or radio tuner 
611 - the signals (packets) are processed immediately without delay and sent to a 
display or audio output. The term Internet Tuner 608 is used to describe the 
invention as an analogy to such signal processing devices. The Internet Tuner 
608 acts as the interface between the Internet signals 609 and application 

20 products such as smart televisions 604, set-top appliances 605, smart telephones 
606, and handheld devices 607. It processes Internet signals 609 in real-time as 
do television 602 and radio tuners 611. 

FIG. 7 illustrates that a full implementation of the invention using the O.S. State 
25 Machine 701, Network Protocol Layer 702, Memory Control 703, Display 
Controller 704, email data handler 708, Interpreters 707, Java Machine 706, and 
WWW Browser 705 may be separated into two separate modules. The modularity 
of the invention allows functions such as the data handlers 713 (email data 
handler 717, Interpreters 716, Java Machine 715, and WWW Browser 714) to be 
30 separated and placed into a high-level ROM code for certain applications. 
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The following application examples further illustrate the versatility of the modular 
design of the invention. 

FIG. 8 demonstrates the possible configurations of the invention for a Network PC. 
5 One variation includes the O.S. State Machine 801, Network Protocol Layer 802, 
Memory Control 803, Display Controller 804, email data handler 808, Interpreters 
807, Java Machine 806, and the WWW Browser 805. This can be varied by 
placing the data handlers for email 817, Interpreters 816, Java Machine 815, and 
WWW Browser 814 code into high-level ROM running on a microprocessor 813. 
10 The microprocessor 813 communicates through the O.S. State Machine 809 for 
network and display functions. A third variation allows a microprocessor 822 
running off of a 3rd Party ROM 823 to interpret the data coming from the Network 
Protocol Layer 819 and O.S. State Machine 818. The microprocessor 822 
displays data through the Display Controller 821. 

15 

Turning to FIG. 9, a handheld device may use only the Network Protocol Layer 
901 and interface it to a custom Transport Mechanism 902 and Existing 
Microcontroller 904. Email functions may be added by including the email data 
handler 905 in the configuration. Further demonstrating the modularity of the 
20 invention, the Network Protocol Layer 911 and Java Machine 910 may be added 
to a handheld device, thereby allowing it to process Java applets. 

Referring to FIG. 10, smart telephones may add email capabilities by 
implementing the O.S. State Machine 1001, Network Protocol Layer 1002, 

25 Memory Control 1003, email data handler 1006, and Display Controller 1004. 
The Display Controller 1004 is capable of controlling Light Emitting Diode (LED), 
Liquid Crystal Display (LCD) displays, or big-mapped displays. A Physical 
Transport Control 1 005 may optionally be added, depending on the connectivity 
requirements of the smart telephone. The O.S. State Machine 1007, Network 

30 Protocol Layer 1008, and Memory Controller 1009 may be added to smart 
telephones with an existing microcontroller 1010. The microcontroller 1010 
performs email functions using a 3rd Party email client code 101 1 . 

11 
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Turning finally to FIG. 11, smart televisions, cable-boxes, Video Cassette 
Recorders (VCRs), Digital Video Disc (DVD) players, and game machines can 
take advantage of the network accessibility offered by the invention. The O.S. 
5 State Machine 1102, Network Protocol Layer 1103, Memory Controller 1104, 
WWW Browser 1107, Java Machine 1106, and (optionally) the Display Controller 
1105 are interfaced to an existing controller 1101. If a controller 1101 is not 
present, the Display Controller 1105 is used. Email 1115 functions are easily 
added due to the modularity of the invention. As noted previously, the data 
10 handlers for email 1124, Interpreters 1123, Java Machine 1122, and WWW 
Browser 1121 code are optionally placed into high level ROM running on a 
microprocessor 1 120. The microprocessor 1 120 communicates through the O.S. 
State Machine 1 1 16 for network and display functions. 

15 Example of Packet Reception 

Fig. 12 depicts a received network packet. The packet contains the following 
items as shown from left to right: 

20 - PPP header 
IP header 
TCP header 
JPEG Data 

PPP FCS (Field Checksum) 

25 

The line labeled PPP LAYER ENABLE is activated when a valid start byte is 
detected, and is generated within the PPP block in Fig. 13. Once this line goes 
high, the rest of the PPP block is activated. Within the PPP header is a field 
indicating the type of protocol that the PPP packet is encapsulating. In an 
30 uncompressed PPP header, these are bytes 4 and 5 (counting the start byte 
0x7e). In Fig. 12, these bytes are 0x00 and 0x21 indicating that the encapsulated 
data is an IP packet. After decoding this field, the PPP block activates the IP 

12 
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LAYER ENABLE and PPP DATA FIELD signals, which together enable the IP 
block in Fig. 13. The IP LAYER ENABLE line is decoded from the PPP protocol 
field, and the PPP DATA FIELD line indicates that the incoming data byte stream is 
in the data field portion of the network packet. These two lines must be active for 
5 the IP block to be enabled. Once the IP block is enabled, it starts to parse the 
incoming data bytes. Referring back to Fig, 12, the data immediately following the 
PPP header is the IP header. Within the IP header is a field indicating the type of 
data that is encapsulated within the IP packet. In Fig. 12, this field is shown to be 
0x06 indicating that the encapsulated data is a TCP packet. The TCP LAYER 

10 ENABLE line is activated in response to the IP block decoding this field. The IP 
DATA FIELD line goes active a couple of bytes later, because there are some 
bytes that come between the IP header protocol field and the start of the IP data 
field. The IP DATA FIELD signal indicates that the incoming data byte stream is in 
the data field portion of the network packet. Both the TCP LAYER ENABLE and IP 

15 DATA FIELD lines must be active in order for the TCP block in Fig. 13 to be 
enabled. Once the TCP block is enabled, it starts to parse incoming data bytes. 
Referring back to Fig. 12, the data immediately following the IP header is the TCP 
header. Within the TCP header is a 2 byte field for the destination port. This field 
indicates which application or data handler the encapsulated data is meant for. In 

20 Fig. 12, this field decodes to port 0x0003. In Fig. 13, port 3 is designated as the 
HTTP port. After decoding the destination port field within the TCP header, the 
HTTP ENABLE line is activated, The TCP DATA FIELD line is activated a couple of 
bytes later because there are some intermediate bytes between the destination 
port field and the start of the TCP data field. Both the HTTP ENABLE and TCP 

25 DATA FIELD lines must be active for the HTTP/PORT3 block in Fig. 13 to be 
enabled. Once the HTTP block is enabled, it starts to parse incoming data bytes. 
When it decodes the JPEG header, it enables the JPEG decoder block in Fig. 13. 
Once the JPEG decoder is enabled, it starts to process incoming bytes. The JPEG 
enable line is the only line needed to enable the JPEG block. 

30 
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Although the invention is described herein with reference to the preferred 
embodiment, one skilled in the art will readily appreciate that other applications 
may be substituted for those set forth herein without departing from the spirit and 
scope of the present invention. Accordingly, the invention should only be limited 
5 by the Claims included below. 
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CLAIMS 

1. An apparatus for decoding and encoding network protocols and data, 
comprising: 

5 a network protocol layer module for encoding and decoding network 

packet bytes; 

a data handler module; 

a memory control module; and 

a operating system (o.s.) state machine module. 

10 

2. The apparatus of claim 1 , wherein said network protocol layer comprises a 
plurality of state machines representing different network protocols. 

3. The apparatus of claim 2, wherein said network protocol layer implements 
15 one or more of the following network protocols: Point to Point Protocol (PPP), 

Internetwork Packet (IP), Transmission Control Protocol (TCP), Raw Socket, 
and/or User Datagram Protocol (UDP). 

4. The apparatus of claim 2, wherein said network packet bytes are processed 
20 in real time. 

5. The apparatus of claim 2, wherein said network packet bytes are processed 
concurrently. 

25 6. The apparatus of claim 2, wherein said network packet bytes are processed 
byte-serially. 

7. The apparatus of claim 1, wherein said network protocol layer is an 
hardware gate-level circuit. 

30 
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8. The apparatus of claim 1 , wherein any data required more than once by a 
specific said state machine is placed in a specific memory location with a pointer 
designating said memory location, 

5 9. The apparatus of claim 1, wherein said data handler comprises at least one 
state machine which processes a specific data type(s), 

10. The apparatus of claim 9, wherein said data handler processes one or 
more of the following data types: Hypertext Transfer Protocol (HTTP), Hypertext 

1 0 Markup Language (HTML), Post Office Protocol (POP3), Internet Message Access 
Protocol (IMAP4), Simple Mail Transfer Protocol (SMTP), Joint Photographic 
Experts Group (JPEG), Graphics Interchange Format (GIF), and/or Java language. 

1 1 . The apparatus of claim 9, wherein said data type is processed in real time. 

15 

12. The apparatus of claim 9, wherein said data types are processed 
concurrently. 

13. The apparatus in claim 9, wherein said data types are processed byte 
20 serially. 

14. The apparatus of claim 9, wherein said data handler is an hardware gate 
level circuit. 

25 15. The apparatus of claim 9, wherein said data handler is an high-level Read 
Only Memory (ROM) program, 

16. The apparatus of claim 9, wherein any data shared by said state 
machine(s) or required more than once by a specific said state machine is placed 
30 in a specific memory location with a pointer designating said memory location. 
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17. The apparatus of claim 9, wherein any data shared by said state 
machine(s) is provided to said state machine(s) concurrently. 

18. The apparatus of claim 1, wherein said memory control module arbitrates 
5 all memory accesses. 

19. The apparatus of claim 1, wherein said memory control module contains a 
Unified Memory Architecture (UMA) which allows the system and video memory to 
reside in the same memory area. 

10 

20. The apparatus of claim 1, wherein said memory control module is 
comprised of one or more arbiter logic blocks where an arbitor block arbitrates 
according to a dynamic rotating algorithm between two devices. 

15 21. The apparatus of claim 1, wherein said memory control module is 
comprised of one or more arbitor logic blocks arranged in such a manner as to 
give a fixed weighted priority to each device for memory access based on a given 
arbitor tree structure. 

20 22. The apparatus of claim 1, wherein said o.s. state machine acts as an 
arbitrator between said network layer, said data handler, and said memory control 
modules for resource control, system and user interface. 

23. The apparatus of claim 1 , further comprising: 
25 a display controller. 

24. The apparatus of claim 23, wherein said display controller controls one of 
the following types of displays: VGA, television, Liquid Crystal Display (LCD), or 
Light Emitting Diode (LED). 

30 
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25, The apparatus of claim 23, wherein said network layer, said data handler, 
said memory control, said o.s. state machine, and said display controller are an 
hardware gate level circuit. 

5 26. The apparatus of claim 1 1 wherein said apparatus acts as an Internet tuner 
for consumer appliances. 

27. An process for decoding and encoding network protocols and data, said 
process comprising the steps of: 
1 0 encoding and decoding network packet bytes; 

processing packet data bytes; 

controlling memory accesses; and 

controlling state machine sequencing. 

15 28. The process of claim 24, wherein said step of encoding and decoding 
network packet bytes further comprises the step of: 

representing different network protocols using a plurality of state machines. 

29. The process of claim 28, wherein said step of encoding and decoding 
20 network packet bytes further comprises the step of: 

encoding and decoding one or more of the following network protocols: 
Point to Point Protocol (PPP), Internetwork Packet (IP), Transmission Control 
Protocol (TCP), Raw Socket, and/or User Datagram Protocol (UDP). 

25 30. The process of claim 28, wherein said step of encoding and decoding 
network packet bytes further comprises the step of: 
processing network packet bytes in real time. 

31. The process of claim 27, wherein said step of encoding and decoding 
30 network packet bytes further comprises the step of: 
processing network packet bytes concurrently. 
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32. The process of claim 27, wherein said step of encoding and decoding 
network packet bytes further comprise the step of: 

processing network packet bytes in a byte serial fashion. 

5 33. The process of claim 27, wherein said step of encoding and decoding 
network packet bytes is an hardware gate-level circuit. 

34. The process of claim 27, wherein said step of processing packet data bytes 
further comprises the step of: 
1 0 processing specific data type(s) using at least one state machine. 



35. The process of claim 34, wherein said step of processing packet data bytes 
further comprises the step of: 

use of a CRC algorithm to decode data fields. 

15 

36. The process of claim 34, wherein said step of processing packet data bytes 
further comprises the step of: 

processing one or more of the following data types: Hypertext Transfer 
Protocol (HTTP), Hypertext Markup Language (HTML), Post Office Protocol 
20 (POP3), Internet Message Access Protocol (IMAP4), Simple Mail Transfer Protocol 
(SMTP), Joint Photographic Experts Group (JPEG), Graphics Interchange Format 
(GIF), and/or Java language. 



37. The process of claim 34, wherein said step of processing packet data bytes 
25 further comprises the step of: 

processing packet data bytes in real time. 

38. The process of claim 34, wherein said step of processing packet data bytes 
further comprises the step of : 

30 processing packet data bytes concurrently. 
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39. The process of claim 34, wherein said step of processing packet data bytes 
further comprises the step of: 

processing packet data bytes in a byte serial fashion. 

5 40. The process of claim 34, wherein said step of processing packet data bytes 
is an hardware gate level circuit. 

41 . The process of claim 34, wherein said step of processing packet data bytes 
is a program. 

10 

42. The process of claim 34, wherein said step of processing packet data bytes 
further comprises the step of: 

placing any data more than once by a specific said state machine in a 
specific memory location with a pointer designating said memory location. 

15 

43. The process of claim 27, wherein said step of controlling memory accesses 
further comprises the step of: 

arbitrating all memory accesses. 

20 44. The process of claim 27, wherein said step of controlling memory accesses 
further comprises the step of; 

allowing the system and video memory to reside in the same memory area 
using a Unified Memory Architecture (UMA). 

25 45. The process of claim 27, wherein said step of controlling state machine 
sequencing further comprises the step of: 

arbitrating between said step of encoding and decoding network packet 
bytes, said step of processing packet data bytes, and said step of controlling 
memory accesses for resource control, system and user interface. 

30 
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46. The process of claim 27, wherein said step of controlling state machine 
sequencing further comprises the step of: 

interpreting system and user input for the purpose of controlling said data 
handler modules, and said network protocol layer modules. 

47. The process of claim 27, further comprising the step of: 
displaying output data. 



48. The process of claim 47, wherein said step of displaying output data further 
1 0 comprises the step of: 

controlling one of the following types of displays: VGA, television, Liquid 
Crystal Display (LCD), or Light Emitting Diode (LED). 

49. The process of claim 47, wherein said process is an hardware gate level 
1 5 circuit. 



50. The process of claim 27, wherein said process is an Internet tuner for 
consumer appliances. 
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